The edenSurvivalRate represents the fraction of Eden regions that
survived a PGC (nominally in the range [0.0, 1.0]).  An overflow
(rate > 1.0) can cause incorrect heap/Eden size adjustments, producing
unexpected allocation spikes and, in extreme cases, out-of-memory
errors.  The issue is not a regression but was exposed by a recent
Eden-resize change.

Four overflow sources are addressed:

1. Incorrect edenCountBeforeCollect (denominator)
   During a PGC the heap may expand, triggering an Eden size
   recalculation.  The newly calculated Eden size can differ
   significantly from the size at collection start, making the survival
   rate inaccurate.  Fix: use copyForwardStats->_edenEvacuateRegionCount
   as the denominator instead of getCurrentEdenSizeInRegions(env).

2. Semantic mismatch between edenSurvivorCount and edenEvacuateCount
   In the first few PGCs after a GMP, previous Eden survivors are
   ADDRESS_ORDERED_MARKED regions with logicalAge == 0.  They enter the
   evacuate set as non-Eden regions, but their surviving objects spill
   into age-0 survivor regions that are counted as Eden survivors.
   This can cause _edenSurvivorRegionCount > _edenEvacuateRegionCount.

3. Over-counting of Eden survivor regions (shared fresh survivors)
   Because Eden and age-0 non-Eden regions share the same compact group,
   they can fill the same fresh survivor regions, causing
   _edenSurvivorRegionCount to be over-counted.

Fix2/3:Use edenEvacuateBytes(=edenCountBeforeCollect * regionSize) and
edenSurvivorBytes(= copyForwardStats->_copyBytesEden) instead of
 edenSurvivorCount and nonEdenSurvivorCount to prevent Semantic mismatch
 and Over-counting issues.

TODO: To improve the accuracy of edenSurvivalRate, edenEvacuateBytes
should exclude the free bytes remaining in evacuated Eden regions
(region->getMemoryPool()->getFreeMemoryAndDarkMatterBytes()),
as they do not represent evacuated live data.

4. _scanBytesEden double-counting (cap)
   During abort recovery, objects that were partially copied (forwarding
   pointer already installed) are scanned again in the source region,
   double-counting their bytes in _scanBytesEden.
   this can push edenSurvivorBytes above edenEvacuateBytes.
   Fix: cap edenSurvivorBytes at edenEvacuateBytes and add an
   assertion that thisSurvivalRate <= 1.0.

Signed-off-by: lhu <linhu@ca.ibm.com>